Is there any harm to this being the default behavior and dropped the need for a flag entirely? As in, why wouldn't we always just include an optimized WASM as part of the build process?

I'm not opposed to that, especially because the additional-libs feature is enabled by default.

wdyt, @leighmcculloch?

Is there any harm to this being the default behavior and dropped the need for a flag entirely? As in, why wouldn't we always just include an optimized WASM as part of the build process?

I think we need to be really confident about wasm-opt and what it does to files if it is the default behaviour on. So maybe lets open an issue about that and explore that separately to this issue.

I think we need to be really confident about wasm-opt and what it does to files if it is the default behaviour on

To be clear, I think we should output both, not just the one optimized variant always.

I think we should output both

Why? It creates an experience that's not the same as how just using cargo build and the rust compiler works, and in general we've tried to make this as much as possible the "standard rust experience" in as many subtle ways as possible. So I think if we keep the separate file we should have a reason we're continuing to do that.

Why?

@leighmcculloch eh, just a convenience thing I guess. I would, as a developer, like the optimized version available (for visibility, if anything: I bet a decent number of devs don't even know we have an optimizer) without having to do extra steps so that I can deploy that one to mainnet when I'm ready. I get that it deviates from Rustisms, but it is better devx imo.

Edit: I didn't realize that we may not want to recommend the optimized one by default, though, which changes the equation a bit from our perspective by making it explicitly opt-in.